Add initial handling for long I2C reads. #751
Conversation
| //WAIT Transmission | ||
| uint32_t startAt = millis(); | ||
| while(1) { | ||
| //have been looping for too long | ||
| if((millis() - startAt)>50){ | ||
| log_e("Timeout! Addr: %x", address >> 1); | ||
| if((millis() - startAt)>50) { |
There was a problem hiding this comment.
If you exit right here, the I2C State Machine is Where? I think some Reset/Cleanup action need to be executed. The I2C protocol allows the Slave device to pause the Master by holding SCL low. I have not been able to determine the 'Official' maximum pause. Philips UM10204: pg.48 says 'Tlow min 4.7us, max = unlimited. So, theoretically, a valid transaction could take until the death of the Universe!
There was a problem hiding this comment.
If we are exiting at that point, it is because the state machine has failed or the slave is not responding. The program needs to decide how to handle such as by calling i2cReset to reset the hardware state machine.
The problem with the current ESP32 hardware implementation of I2C is that it really doesn't support the slave holding the SCL low for very long at all. There is a timer in i2cInit that I have set to its longest value on line 455. I tried setting it longer with no additional benefit so it appears to be at its actual maximum. Numerous people have commented on this implementation flaw but the current version of the chip is what it is. In the IDF forums, making the ESP I2C implementations compliant to the spec is one of the big requests for the next chip revision.
There was a problem hiding this comment.
@lonerzzz Have you thought about address NAK, and Arbitration Lost errors? If you setup a list of cmd ops:
- start
- write address (to select the address of the Slave)
- Read block of bytes
- Stop
And then you get a address NAK, does that cause the I2C StateMachine(SM)to halt? or does is continue with the READ command? The Docs are very Fuzzy!
I was just thinking that if an Address NAK event happened, you should cleanup the CMD Stack and ReInit the SM back to an Idle condition. Then return the NAK error to the APP.
There was a problem hiding this comment.
Oh, yeah, the docs need some work. When I finally got through to the espressif folks a week ago, they indicated they were working on I2C code fixes as well as documentation and would like my fix to include so I was trying to get it done amongst other tasks. The good news is at least we know some more improvements are coming. They are definitely needed.
To your question. my understanding is that most errors do cause the SM to halt as one would expect but I have seen situations where that was not the case but 'reproducability' was the biggest obstacle to getting to the root of it.
You are correct. We could clean up on the NAK if we can confirm that the SM is stable enough to properly stop the pipeline. My assumption so far has been that in these situations, I let the application layer call i2cReset and reset the whole state machine simply because I am not sure of what all the problems with the SM are.
| @@ -269,86 +283,90 @@ i2c_err_t i2cRead(i2c_t * i2c, uint16_t address, bool addr_10bit, uint8_t * data | |||
| i2cResetCmd(i2c); | |||
|
|
|||
| //CMD START | |||
| i2cSetCmd(i2c, 0, I2C_CMD_RSTART, 0, false, false, false); | |||
| i2cSetCmd(i2c, cmdIdx++, I2C_CMD_RSTART, 0, false, false, false); | |||
|
|
|||
| //CMD WRITE ADDRESS | |||
There was a problem hiding this comment.
10 bit address are sent high byte, low byte. Also the address is modified before it is sent.
Philips UM10204 pg.15 3.1.11 10-bit addressing:
The first 7 bits of the first byte are the combination of 1111 0xx of which the last two bits (xx) are the two Most-Significant Bits (MSB) of the 10-bit address; the eighth bit of the first byte is the R/W bit that determines the direction of the message.
So, This section should be changed to:
// address contains left shifted address with bit0 set for READ
if(addr_10bit){
i2c->dev->fifo_data.val =((address>>8)& 0x06) | 0xF1; // send a9:a8 and read bit with 1111 0xxR mask
i2c->dev->fifo_data.val=((address>>1) & 0xFF); // send a7:a0
}
else{
i2c->dev->fifo_data.val=(address & 0xFF) ; // send a6:a0 with READ bit
}There was a problem hiding this comment.
This code shown is filling the transmission pipeline, it is not about the addressing, but rather the COMMAND buffer that holds the series of I2C actions to perform.
I assume you are referring to the next block for CMD WRITE ADDRESS, I see your point. I didn't even look at this code and just moved it as I was focused on the long reads and my hardware only uses 7 bit addresses. You should raise a separate issue for the addressing issue.
There was a problem hiding this comment.
@lonerzzz Ok, I'll create a pull with just this 10bit addressing in the i2cWrite() and i2cRead().
There was a problem hiding this comment.
@stickbreaker, I'll put in your 10 bit fix following mine if @me-no-dev accepts my fix. Let me know if there are concerns.
There was a problem hiding this comment.
Ya, Just replace the existing code for 10bit addresses in BOTH i2cWrite() and i2cRead() with my snippet. That way any 10bit address will match Industry specs.
Chuck.
|
guys what is the state here now? should I merge this? @stickbreaker yours second? |
|
My fix does work. I have been running it for 2 weeks, but I asked @stickbreaker to submit a parallel request in case there were concerns with my submission. If we put in my fix, then we should not put in his. I will follow up with a submission also containing his fix. |
|
@me-no-dev apply this pull. Then my pull, Since @lonerzzz is going to incorporate my change it will all work out. Chuck. |
|
let me know when everything is ready :) |
|
Yo Guys :) might want to look into: espressif/esp-idf@01befe4 |
|
@me-no-dev Do you have a rough time frame when this code will be picked up for Arduino? What I do not see in the code is any specific handling for long messages. I am also not sure if it would handle all recovery scenarios. I will try it once it is in the Arduino and modify for long messages and recovery if needed. |
|
@lonerzzz I looked through that code and found a couple of typo's. Also I have some questions about how they are using portEnter_CRITICAL(mux) calls (aliased to I2C_ENTER_CRITICAL(mux)). I created a pull espressif/esp-idf/#1180 with my suggested changes but have not received any feedback. When it gets to the Arduino fork, esp_hal_i2c.x will either have to be rewritten or replaced. @me-no-dev The It has some statemachine lockup recovery sequences, and handles the fifo write calls with I'm playing with an I2C HAL modification that uses interrupts for all of the data handling. I was thinking about having Chuck. |
|
Generally if we can use the IDF driver and that does not cause some huge time impacts (like it does for SPI) then we should use the same driver and focus our efforts on it. If it costs too much time, then we need to look into what we can improve here. When I wrote the Arduino driver, one was not even available for IDF :) |
|
@me-no-dev That makes sense. Then, just to confirm, the suggestion is to rewrite the esp32-hal-i2c .c and .h files to use the i2c .c and i2c.h files? I will ask the IDF folks about getting the changes in place to continually update command structure so we can handle long messages. |
|
@lonerzzz @me-no-dev Do either of you know the correct sequence to continue from an I2C_END_DETECT_INT_ST? Currently I am receiving the interrupt, dev->ctr.trans_start=0;
//filling command[0],command[1]...
cmdIdx=0;
fillReadQueue(i2c,&neededRead,cmdIdx);
dev->int_ena.end_detect =1;
dev->int_clr.end_detect =1;
dev->ctr.int_ena.end_detect =1;
dev->int_clr.val =$FFFFFFFF;
dev->ctr.trans_start=1;I return from the interrupt, then I receive a I2C_TIME_OUT_INT. Then the I2C statemachine goes crazy. any suggestions? |
|
@stickbreaker END is broken and that is why my read code that I submitted does not use it. Once called, the state machine gets into a non-recoverable state. What my code effectively does is to keep the circular command buffer constantly updated with 2 future commands and the state machine simply wraps in executing commands from the command buffer until it reaches a STOP. That way it can execute commands indefinitely. If playing with interrupts, you should be able to do the same thing of keeping 2 steps ahead in the command buffer while also avoiding the timing issues. I will get back to this in the following week, but had some other priorities that stole my time after the last submission. |
|
@lonerzzz And The data is correct! I just executed a 9000 byte read from a 24LC32 (4k) so it displayed the entire EEPROM 2 and 1/4 times. This is weird. Why does it work now? Do you have any specifics on the END failure modes. I did have a 8192 fail. the following is my debug output, the log_e (647) are the last 31 dev->int_status values. the Chuck. |
|
@stickbreaker When I was playing with it, the problem was one of consistency. I did occasionally have successful reads but generally there was no recovery after calling an END. The clock was a part of the issue and it would get into a state where it would just keep toggling for some period of time with the data being read not being valid. The data read had lots of 0xFF data values in the values and would encounter timeouts because the clock was cycling for so long. As well, adding print outs during the process changed the timing so I had to work without them. Some commentary that I read indicated that the START could not directly follow the END command and my suspicion was one of timing. Hence why my implementation avoid the END usage entirely as it seems to have several timing issues. |
|
Also just noticed that you are using 35 byte reads. Since the buffer is only 32 bytes in length, you will be getting lots of nonsensical bits in your results. |
|
@lonerzzz Since I am using the I realized the active I have validated the data, I am not missing anything. When you said:
Did you mean Also to play around I have been changing I successfully ran tens of big block reads from 64 bytes clear up to 32768 for about 3hrs last night. I did not get any failures after that 8192 I listed. That makes me nervous. Why did that one fail, but the rest of these succeed? Today one of my experiments will be to mess with fifo ops, change the Maybe I'll have a go at My real targets are Chuck. |
|
@stickbreaker Not having tried the interrupts on read receipt, I wasn't sure when the interrupt would be coming. Obviously if you get the notifications in time to process the data we are all good. That is a relief. I am glad you are making progress. For the START not following the END command, my understanding was that it was for the command ctr.trans_start triggering since nothing happens after an END unless trans_start is set anyway. I suspect that this is a hardware timing issue based on my tests. Some people were adding delays and putting commands in between but none of those approaches were going to be universally I2C compliant as there was additional signalling happening on I2C that some slaves would object to. I too played with the clock rate and found it could go quite fast. I even added a I2C level amplifier to compensate for the capacitance but it was the state machine timing always causing the issues so I am curious how much your use of the interrupts helps resolve this. What sort of message success rate are you getting on the initiated reads at this point with the interrupt handling approach? You mentioned 10's of big block reads with 1 error so that could just as easily be a bus noise error. Are you able to run reads at something like 1K, 10K and then 100K sizes each for a 5 minute interval to get a bit error rate? With size variations like these, we can then see if there is differential on the error rate for message starts versus the number of bytes. In other words, if the state machine is causing problems, then it should show up more often for short messages because they will have more starts. If it is simply a bus noise problem, it should show up roughly evenly for both small and large messages since the overall number of bits transferred will be roughly the same. I won't get to it until Tuesday at least, but if you have some code you want to share, I would be interested to see what you have working. |
|
@lonerzzz Your interest in the error rates started me thinking about building a automated continuous testing cycle. Currently my code outputs the received block to Do you think a checksum would be enough, currently I do a byte to byte comparison between my newRequestFrom() and a constructed block build from: uint16_t addr; // these values are set manually through Serial
uint16_t testSize; // manual
uint8_t *compBuff =(uint8_t*)calloc(testSize,sizeof(uint8_t));
uint16_t a=0,b=0;
uint8_t err=0;
bool fail=false;
while((a<testSize)&&(!fail)) {
Wire.beginTransmission(ID);
Wire.write(highByte(addr));
Wire.write(lowByte(addr));
err=Wire.endTransmission();
fail =(err!=0);
if(!fail){
uint8_t readSize = ((testSize-a)>16)?16:(testSize-a);
err=Wire.requestFrom(ID,readSize);
if(err==readSize){
while(Wire.available()){
compBuff[a++]=Wire.read();
addr++;
}
else {
fail = true;
Serial.printf("requestFrom failed at %d\n",addr);
}
}
else {
Serial.printf("Address write failed at %d=%d\n",addr,err);
}I made a real hash of the I2C_struc.h and I2C_reg.h. I'll clean them up and push my changes to stickbreaker/arduino-esp32. My testing sketch will be in stickbreaker/esp32-i2c-test. It will probably take a couple of days, so your Tuesday time would be about right. Chuck. |
|
It depends what you mean by a checksum as come can be heavy in terms of processing which slows the rates and affects the tests being performed. For this type of testing, I typically use a CRC-8/16 code as they are all implemented as incremental processing. There are numerous available which should do the job. eg: Jason |
|
@lonerzzz I think I found Stop After End, not Start after end. I think what happens, is that the END command is not completed until after the return from interrupt END_DETECT. So, if you change the element where END resides, bad things happen. A read command sequence has a minimum of START,WRITE,READ_NAK,STOP. The Continuation command fits in START,WRITE,(READ_ACK)*13,END + [READ_ACK,] READ_NAK,STOP. As I write this, my ESP32 has completed 6400 iterations in the last 30 minutes: blockLen ++;
addr --;
// use Wire.beginTransmission() to set 24LCxx address
uint8_t *buff=(uint8_t*)calloc(blockLen,sizeof(uint8_t));
uint16_t cnt = Wire.newRequestFrom(ID,buff,blockLen,true);
// test
free(buff);Without any errors, It is taking about 591ms for each block now. Chuck. |
|
@lonerzzz Another Observation. That is what I think. But, I am unsure if it is accurate. The Existing code in hal-i2c just issues a END if sendStop is false? I'm going to ask people that have posted I2C stability problems if their devices use the ReStart operation. Chuck. p.s. that test is at 14140, I sped it up to 400k at the 10000 mark, still no errors! so, it has moved 102MB with no problems! |
|
@stickbreaker That is an interesting finding regarding the END position. Sounds a bit different with the interrupt handling than what I I was seeing but definitely fits with by observations of weirdness around the END usage. Sounds like you have something much more stable. |
|
Just saw your next message coming in while I finished the last. Seems the stability is very good. What size messages are you sending? I have not observed the need for a STOP on every transaction. That seems odd to me as I was breaking up things into multiple 31 and 1 byte reads for the polled approach and had no STOP until the end. The reads worked fine in that scenario. Unless you are talking about an infrequent error that happens without the STOP being used each time. The existing code was sending the END if there were more bytes to read but that is totally dependent on filling up the 32 byte buffer and handling it based on the polling approach. With the use of interrupts, you are covering new ground so that logic doesn't really fit anymore. You would only need an END if the total amount of bytes to move exceeded 255*13 I think based on 3 positions in the command buffer used for start, stop, etc. |
|
@lonerzzz The test increments the buffer size by one byte each time, currently it is at 18,750 bytes long. It decrements the starting address by 1 for each read. The time out defaults to 1M clocks (2^20 APB clock cycles) as long as no task switch happened, you were probably ok. Chuck. |
|
@lonerzzz had to kill the test at 26511, Still working though! |
|
@stickbreaker That is cool. Looking forward to trying out your rework. You will probably be teaching the IDF folks a thing or two with the changes. |
|
@stickbreaker I read in another thread that you are going down a path for adding I2C slave support. You had mentioned putting some code in stickbreaker/esp32-i2c-test after cleanup. Any chance of getting something pushed? I would be keen to play with what you have. |
|
@lonerzzz as soon as I get this version working I'll push it to my Arduio-esp. I'm generalizing the ISR to handle both Master Read/Write. My test cases were just enough to handle a Read or a Write. Now I am in the process of changing it to handle a command list of operations. I got sidetracked with the Chuck. |
|
@stickbreaker Yeah the timeout reset handling is a serious weak point of the current hardware. I think we are really caught with a part that was rushed to market. When you have anything you want to share, let me know and I will do some testing. Cheers. |
|
@lonerzzz Ok, Jason, in my Github Arduino-Esp I just push the changes that allow a ISR to work, It is not pretty, It is NOT anything other than testing software. It assumes an ESP32, 24LCxx at 0x50. the test sketch is i2c_Scan.ino in Esp32-i2c after you upload the sketch, the Serial terminal (115200,newline), try these commands:
A lot of debug is emitted. The important files are It is really ruff, the Interrupt "features" of this chip are atrocious! Chuck. |
|
@stickbreaker I have pulled it down and will try it out. Thank you. Looks like you have been trying quite a number of things... Just noticed that Wire is not in your repo and don't see a branch on esp32 repo. What am I not seeing? |
|
@lonerzzz I forgot it. It is now updated. Chuck. |
|
@lonerzzz Another thing, Chuck. |
|
@stickbreaker It is still not there from my view, neither in esp32 or in your repo. Where should I be seeing the latest additions? |
|
@lonerzzz I pushed the missing Chuck. |
|
@stickbreaker Sorry if I am being a pain, but my first issue is that I cannot see your Wire.h and Wire.cpp files in the https://github.com/stickbreaker/ESP32-i2c location if that is where you have them. I see only three files, ESP_I2C_TEST, I2C_Scan.h and I2C_Scan.ino which I have pulled. I also do not see any branch under https://github.com/espressif/arduino-esp32. I am not seeing either online or through my git client. Scratching my head... |
|
@lonerzzz They are in my local fork of "Arduino-ESP32" at here Arduino-ESP |
|
@stickbreaker Thank you. All good now. |
|
I'm pushing ahead with MASTER mode, I think I can see a way to achieve Async support using EventGroups. I have a personal project that uses I2C EEPROMS as storage for a TinyFat file system. It will be nice to read contiguous sectors with one Read, or the whole file with a queue of reads all pointing at a local buffer. No more |
|
@lonerzzz I Just updated my fork with an ALPHA that works for me. Try it. |
|
@stickbreaker Great to hear! I will test in an hour or so and into the evening. |
origin https://github.com/espressif/esp32-arduino-lib-builder (fetch) origin https://github.com/espressif/esp32-arduino-lib-builder (push) * master commit 2938705 Author: me-no-dev <[email protected]> Date: Sat Jun 25 00:33:26 2022 +0300 Implement memory variants on all chips to fix flash modes diff --git tools/config.sh tools/config.sh index a403109..95c3d51 100755 --- tools/config.sh +++ tools/config.sh @@ -28,7 +28,7 @@ IDF_COMPS="$IDF_PATH/components" IDF_TOOLCHAIN="xtensa-$IDF_TARGET-elf" # Owner of the target ESP32 Arduino repository -AR_USER="espressif" +AR_USER="nomis" # The full name of the repository AR_REPO="$AR_USER/arduino-esp32" Build command: ./build.sh -A sa-2.0.3 -i b8050b365e origin https://github.com/hathach/tinyusb.git (fetch) origin https://github.com/hathach/tinyusb.git (push) * master commit ecb899408bb95c5c0d50ebe2d887cd746104c534 Merge: 68c2012ed 53db23142 Author: Ha Thach <[email protected]> Date: Fri Jul 1 20:52:46 2022 +0700 Merge pull request espressif#1544 from hathach/ci-parallel-build Ci parallel build origin https://@github.com/nomis/arduino-esp32.git (fetch) origin https://@github.com/nomis/arduino-esp32.git (push) master * sa-2.0.3 commit 8e1f67e Author: Simon Arlott <sa.me.uk> Date: Sat Jul 2 17:12:37 2022 +0100 Reconfigure origin https://github.com/espressif/esp32-camera.git (fetch) origin https://github.com/espressif/esp32-camera.git (push) * master commit 8575d75b91c0387037b68b3a864ac6696f6e0a2e Author: yuxinwww <[email protected]> Date: Thu Jun 30 20:15:43 2022 +0800 fix: fix ov5640 sys reset to MCU mode reset (espressif#407) origin https://github.com/espressif/esp-dl.git (fetch) origin https://github.com/espressif/esp-dl.git (push) * master commit d9493506707c0b68fa10447ec24380af6f19bb32 Author: yehangyang <[email protected]> Date: Mon Jan 24 17:10:15 2022 +0800 :bug: typo origin https://github.com/espressif/esp-sr.git (fetch) origin https://github.com/espressif/esp-sr.git (push) * master commit d05cf97972c0a324d331437d6a37229a2d96f3cf Author: Wang Wang Wang <[email protected]> Date: Mon Jan 17 17:23:55 2022 +0800 feat(MN_CN): Support chinese continuous recognition origin https://github.com/joltwallet/esp_littlefs.git (fetch) origin https://github.com/joltwallet/esp_littlefs.git (push) * master commit 6a08044e048f47e6da6b6e0b30ccaf832c12b338 Author: Brian Pugh <[email protected]> Date: Wed May 4 15:41:58 2022 -0700 Update README.md origin https://github.com/BrianPugh/mklittlefs.git (fetch) origin https://github.com/BrianPugh/mklittlefs.git (push) * (HEAD detached at a14dabe) master commit a14dabe444e9a265aab04d085d8ca8f8536d799b Author: Brian Pugh <[email protected]> Date: Thu Oct 21 17:37:00 2021 -0700 use parenting project, esp_littlefs, littlefs submodule origin https://github.com/littlefs-project/littlefs.git (fetch) origin https://github.com/littlefs-project/littlefs.git (push) * (HEAD detached at ead5080) master commit ead50807f1ca3fdf2da00b77a0ce02651ded2d13 Merge: 2f75968 1e423ba Author: Christopher Haster <[email protected]> Date: Sat Jun 12 12:35:34 2021 -0500 Merge pull request espressif#565 from tniessen/fix-link-to-test-bd Fix link to test block device origin https://github.com/espressif/esp-rainmaker.git (fetch) origin https://github.com/espressif/esp-rainmaker.git (push) * master commit 00bcf4c Merge: 677a244 07533b8 Author: Piyush Shah <[email protected]> Date: Fri Jun 10 01:02:36 2022 +0800 Merge branch 'task/standard_types' into 'master' Added definitions for various parameters and UI types. See merge request app-frameworks/esp-rainmaker!308 origin https://github.com/espressif/esp-rainmaker-cli.git (fetch) origin https://github.com/espressif/esp-rainmaker-cli.git (push) * (HEAD detached at e61d952) master commit e61d9528c152ceb345d7a37535e8ffb2d004e832 Merge: 040bc43 cc37f73 Author: Piyush Shah <[email protected]> Date: Thu Dec 30 14:03:35 2021 +0000 Merge branch 'bugfix/claim_platform_detect_check' into 'master' claim: Fix search string for autodetection of platform, handle error using esptool, add esp32s3 in supported platforms See merge request app-frameworks/esp-rainmaker-cli!25 origin https://github.com/espressif/esp-insights.git (fetch) origin https://github.com/espressif/esp-insights.git (push) * (HEAD detached at 1d6bb17) main commit 1d6bb172ef5308073f59260c1ed25078f33521f3 Merge: 2f81127 1acc703 Author: Piyush Shah <[email protected]> Date: Thu Jun 2 17:00:31 2022 +0800 Merge branch 'support/large_allocs_spiram' into 'main' Provide an option to move large allocations to SPIRAM See merge request app-frameworks/esp-insights!92 origin https://github.com/espressif/esp-rainmaker-cli.git (fetch) origin https://github.com/espressif/esp-rainmaker-cli.git (push) * (HEAD detached at 8dd8c7f) master commit 8dd8c7f2108c412e679a9262de216cc9ce6858b0 Merge: 25637e8 401179e Author: Piyush Shah <[email protected]> Date: Sat Jan 23 01:22:10 2021 +0800 Merge branch 'task/gitignore' into 'master' Add a .gitignore file See merge request app-frameworks/esp-rainmaker-cli!12 origin https://github.com/intel/tinycbor.git (fetch) origin https://github.com/intel/tinycbor.git (push) * (HEAD detached at 7c349db) main commit 7c349dbb6b8d76db39383b226d3ebdf59b8ab37d Author: Mahavir Jain <[email protected]> Date: Wed Feb 24 11:00:43 2021 +0530 Add checks for memory allocation failures Signed-off-by: Mahavir Jain <[email protected]> origin https://github.com/espressif/esp-rainmaker-common.git (fetch) origin https://github.com/espressif/esp-rainmaker-common.git (push) * (HEAD detached at 2ef3c6f) master commit 2ef3c6f8ffa173a7ce9e263e63c343916e8e0d6c Author: Vikram <[email protected]> Date: Wed May 25 17:31:03 2022 +0530 Fix SPIRAM config check for MEM_*_EXTRAM APIs CONFIG_SPIRAM check is non-existant and not sufficient to define allocation APIs to SPIRAM. Fixed this! Signed-off-by: Vikram <[email protected]> origin https://github.com/espressif/json_generator.git (fetch) origin https://github.com/espressif/json_generator.git (push) * (HEAD detached at 17507cc) master commit 17507cce331e8e2056593dc01f5adf0a8b6f63ef Author: Piyush Shah <[email protected]> Date: Mon Jun 6 15:58:46 2022 +0530 json: Use consts wherever applicable origin https://github.com/espressif/json_parser.git (fetch) origin https://github.com/espressif/json_parser.git (push) * (HEAD detached at 8a60b7a) master commit 8a60b7aa5e9b790686a73c4f992bf0b988a45b7f Merge: d049e71 7a784be Author: Piyush Shah <[email protected]> Date: Wed Jun 1 12:36:09 2022 +0530 Merge pull request espressif#2 from MartinK7/master json_parser: Char pointers are now const, Added non-dynamic parse_sta… origin https://github.com/zserge/jsmn.git (fetch) origin https://github.com/zserge/jsmn.git (push) * (HEAD detached at 053d3cd) master commit 053d3cd29200edb1bfd181d917d140c16c1f8834 Merge: a91022a 0837288 Author: P4t <[email protected]> Date: Thu Apr 2 15:08:12 2020 +0200 Merge pull request espressif#175 from pks-t/pks/struct-type jsmn: declare struct names to allow forward decls origin https://github.com/espressif/esp-rainmaker-common.git (fetch) origin https://github.com/espressif/esp-rainmaker-common.git (push) * (HEAD detached at b40a39e) master commit b40a39e06fc449beed9f57ced2417e9a01aad287 Author: Piyush Shah <[email protected]> Date: Wed May 4 18:20:07 2022 +0530 esp-mqtt: Use mbedtls certificate bundle for server authentication origin https://github.com/espressif/esp-dsp.git (fetch) origin https://github.com/espressif/esp-dsp.git (push) * master commit 07aa7b1c84637ac6621e2e460d4dd2cbe352385d Merge: 89d86a8 ac16b03 Author: Ivan Grokhotkov <[email protected]> Date: Wed Mar 9 19:29:57 2022 +0800 Merge branch 'version/1.2.0' into 'master' version: update to 1.2.0 See merge request idf/esp-dsp!68 origin https://github.com/espressif/esptool (fetch) origin https://github.com/espressif/esptool (push) * master commit 65f861420515217f7b5d209fce288808dc5b1943 Author: radim.karnis <[email protected]> Date: Mon Jun 20 13:28:58 2022 +0200 fix(esp32h2beta2): Flasher stub origin https://github.com/espressif/esp-idf.git (fetch) origin https://github.com/espressif/esp-idf.git (push) * (HEAD detached at b8050b365e) release/v4.4 commit b8050b365ea0ecb2f5a6a743bbea537abd6b3083 Merge: 9b75e5664e 1329b19fe4 Author: Ivan Grokhotkov <[email protected]> Date: Tue Apr 19 15:29:27 2022 +0800 Merge branch 'update/version_4_4_1' into 'release/v4.4' Update version to 4.4.1 See merge request espressif/esp-idf!17791 origin https://github.com/espressif/asio.git (fetch) origin https://github.com/espressif/asio.git (push) * (HEAD detached at f31694c9) idf commit f31694c9f1746ba189a4bcae2e34db15135ddb22 Author: David Cermak <[email protected]> Date: Mon May 18 16:41:32 2020 +0200 ESP Platform SSL support for both OpenSSL/mbedTLS and wolfSSL origin https://github.com/kmackay/micro-ecc.git (fetch) origin https://github.com/kmackay/micro-ecc.git (push) * (HEAD detached at d037ec8) master commit d037ec89546fad14b5c4d5456c2e23a71e554966 Author: Ken MacKay <[email protected]> Date: Sun May 21 11:05:04 2017 -0700 Add note that uECC_VLI_NATIVE_LITTLE_ENDIAN affects key compatiblity origin https://github.com/espressif/esp32-bt-lib.git (fetch) origin https://github.com/espressif/esp32-bt-lib.git (push) * (HEAD detached at b877f7e) master commit b877f7e1fc98dccfcf4dbf31f215c5cb44ec3f0d Author: xiongweichao <[email protected]> Date: Mon Feb 21 15:05:00 2022 +0800 update esp32 bt-lib (5688ed5) Fix crash when host exit sniff mode origin https://github.com/espressif/esp32c3-bt-lib.git (fetch) origin https://github.com/espressif/esp32c3-bt-lib.git (push) * (HEAD detached at 98dcc95) master commit 98dcc9591365b5ac486a9f0b474c36bf8c4ca97b Author: Yang Zhao <[email protected]> Date: Tue Mar 1 14:41:26 2022 +0800 Update ESP32-C3 and ESP32-S3 bt lib (d913766) Add the pll track feature to keep the ble connection stable when the environment temprature increase form 0 to 74. origin https://github.com/espressif/esp-nimble.git (fetch) origin https://github.com/espressif/esp-nimble.git (push) * (HEAD detached at 1dc1ec6e) nimble-1.3.0-idf commit 1dc1ec6e76b0ab3bf93cc9f1ff7a2a09141e7c61 Author: Rahul Tank <[email protected]> Date: Tue Nov 16 19:38:35 2021 +0530 Nimble: Check stack initialization status before executing stack command Previous commit added checks in some functions that can be called without stack initalization. Corrected such instances. origin https://github.com/intel/tinycbor.git (fetch) origin https://github.com/intel/tinycbor.git (push) * (HEAD detached at 7c349db) main commit 7c349dbb6b8d76db39383b226d3ebdf59b8ab37d Author: Mahavir Jain <[email protected]> Date: Wed Feb 24 11:00:43 2021 +0530 Add checks for memory allocation failures Signed-off-by: Mahavir Jain <[email protected]> origin https://github.com/ThrowTheSwitch/CMock.git (fetch) origin https://github.com/ThrowTheSwitch/CMock.git (push) * (HEAD detached at eeecc49) master commit eeecc49ce8af123cf8ad40efdb9673e37b56230f Merge: 150573c 175a834 Author: Mark VanderVoord <[email protected]> Date: Thu Jun 4 13:15:31 2020 -0400 Merge pull request espressif#312 from Skinner927/patch-1 Stop strippables default value from being parsed (Thanks @Skinner927 ) origin https://github.com/throwtheswitch/cexception.git (fetch) origin https://github.com/throwtheswitch/cexception.git (push) * (HEAD detached at 71b47be) master commit 71b47be7c950f1bf5f7e5303779fa99a16224bb6 Author: Mark VanderVoord <[email protected]> Date: Mon Apr 20 13:22:44 2020 -0400 Delete License.txt Remove redundant (and old/incorrect) license origin https://github.com/throwtheswitch/unity.git (fetch) origin https://github.com/throwtheswitch/unity.git (push) * (HEAD detached at cf949f4) master commit cf949f45ca6d172a177b00da21310607b97bc7a7 Author: Mark VanderVoord <[email protected]> Date: Sun May 3 16:03:07 2020 -0400 Bump Version origin https://github.com/obgm/libcoap.git (fetch) origin https://github.com/obgm/libcoap.git (push) * (HEAD detached at 3aa1161) develop commit 3aa11612c143c9734d72022720f33e12506f7a2c Merge: ca44071 94b297a Author: obgm <[email protected]> Date: Mon Sep 27 17:50:33 2021 +0200 Merge pull request espressif#751 from hmalpani/develop coap_mbedtls.c: Fix build fail with client only mbedtls origin https://github.com/eclipse/tinydtls.git (fetch) origin https://github.com/eclipse/tinydtls.git (push) * (HEAD detached at 59055b8) main commit 59055b8a935bc53bf69d002fc089ad4bd08851b2 Merge: f8563a5 bbc8d05 Author: obgm <[email protected]> Date: Fri Jun 4 17:29:46 2021 +0200 Merge pull request espressif#82 from mrdeep1/fixes_70 dtls.c: Validate cookie length in check_server_hello_verify_request() origin https://github.com/espressif/esp-phy-lib.git (fetch) origin https://github.com/espressif/esp-phy-lib.git (push) * (HEAD detached at dcbe608) master commit dcbe6085e0215e2ea6a2e43b1106bdb15807f398 Author: cff <[email protected]> Date: Fri Apr 8 10:49:28 2022 +0800 C3/S3 fix "i2c critical" and iram functions origin https://github.com/espressif/esp32-wifi-lib.git (fetch) origin https://github.com/espressif/esp32-wifi-lib.git (push) * (HEAD detached at 5a0d2aee) master commit 5a0d2aee49633b1a0c0374c2a01ed8c2a10e2fe4 Author: Nachiket Kukade <[email protected]> Date: Mon Feb 28 17:51:04 2022 +0530 esp_wifi: Ignore pmf_capable flag in wifi config (63017e0a) origin https://github.com/espressif/esptool.git (fetch) origin https://github.com/espressif/esptool.git (push) * (HEAD detached at 66e1f16) master commit 66e1f163a4f9a32041ec48b8aa7ab958831f8410 Author: KonstantinKondrashov <[email protected]> Date: Fri Mar 4 18:54:41 2022 +0800 espefuse: Show help when espefuse without commands origin https://github.com/libexpat/libexpat.git (fetch) origin https://github.com/libexpat/libexpat.git (push) * (HEAD detached at 57c7da69) master commit 57c7da69b78e3698e112a6b5da19d5109b8232d1 Merge: 919a2bec fc4652b2 Author: Sebastian Pipping <[email protected]> Date: Sun Jan 16 14:13:19 2022 +0100 Merge branch 'issue-533-prepare-release' (espressif#533) origin https://github.com/espressif/esp-ieee802154-lib.git (fetch) origin https://github.com/espressif/esp-ieee802154-lib.git (push) * (HEAD detached at f7b5e80) master commit f7b5e8059a3bb6f321e79ac3bf2aa4d2a9b93326 Author: Jiacheng Guo <[email protected]> Date: Mon Dec 20 16:02:52 2021 +0800 release: v4.4 (119d3c9) origin https://github.com/DaveGamble/cJSON.git (fetch) origin https://github.com/DaveGamble/cJSON.git (push) * (HEAD detached at d348621) master commit d348621ca93571343a56862df7de4ff3bc9b5667 Author: Alan Wang <[email protected]> Date: Wed Aug 25 19:15:09 2021 +0800 chore: update version and changelog (espressif#610) origin https://github.com/jedisct1/libsodium.git (fetch) origin https://github.com/jedisct1/libsodium.git (push) * (HEAD detached at 4f5e89fa) master commit 4f5e89fa84ce1d178a6765b8b46f2b6f91216677 Author: Frank Denis <[email protected]> Date: Thu May 30 22:13:18 2019 +0200 Don't ignore azure-pipelines.yml origin https://github.com/espressif/esp-lwip.git (fetch) origin https://github.com/espressif/esp-lwip.git (push) * (HEAD detached at 2749568f) 2.1.2-esp commit 2749568fe15df2003f6c3f37f0dfd44f8f01fcd6 Author: xueyunfei <[email protected]> Date: Mon Aug 9 11:53:14 2021 +0800 add function for deinit lwip timers origin https://github.com/espressif/mbedtls.git (fetch) origin https://github.com/espressif/mbedtls.git (push) * (HEAD detached at 8b0e35f2a) mbedtls-2.28.0-idf commit 8b0e35f2ad477fcc2a267cf434528024b8499085 Author: Mahavir Jain <[email protected]> Date: Thu Nov 18 15:39:30 2021 +0530 bignum: add provision for combined software and hardware MPI approach For exponential mod (API mbedtls_mpi_exp_mod) operation, some ESP target chips needs to have ability for both hardware and software implementation. Hardware implementation provided performance advantage but it can only support upto 3072 bit operations (e.g., ESP32-C3) and hence we fallback to software implementation in such cases (e.g., 4096 bit operations). Earlier this was handled using linker "--wrap" flag but that does not work in all scenarios as API `mbedtls_mpi_exp_mod` is being used in same tranlation (compilation unit). This approach was found to be next best option with minimal changes in mbedTLS library. origin https://github.com/espressif/esp-mqtt.git (fetch) origin https://github.com/espressif/esp-mqtt.git (push) * (HEAD detached at 89894bd) master commit 89894bd0c611b1392967fe90bb49682eba858383 Merge: 1d10608 1b009c8 Author: David Čermák <[email protected]> Date: Wed Sep 15 18:10:50 2021 +0000 Merge branch 'feature/configurable_retransmit' into 'master' Add configurable retransmit (GitHub PR) See merge request espressif/esp-mqtt!110 origin https://github.com/nghttp2/nghttp2.git (fetch) origin https://github.com/nghttp2/nghttp2.git (push) * (HEAD detached at 8f7b008b) master commit 8f7b008b158e12de0e58247afd170f127dbb6456 Author: Tatsuhiro Tsujikawa <[email protected]> Date: Tue Jun 2 21:05:34 2020 +0900 Update bash_completion origin https://github.com/mruby/mruby (fetch) origin https://github.com/mruby/mruby (push) * (HEAD detached at 7c91efc1f) master commit 7c91efc1ffda769a5f1a872c646c82b00698f1b8 Author: Hiroshi Mimaki <[email protected]> Date: Thu Apr 4 09:26:40 2019 +0900 Update version and release date. `mruby 2.0.1 (2019-4-4)` origin https://github.com/tatsuhiro-t/neverbleed.git (fetch) origin https://github.com/tatsuhiro-t/neverbleed.git (push) * (HEAD detached at b967ca0) master commit b967ca054f48a36f82d8fcdd32e54ec5144f2751 Author: Tatsuhiro Tsujikawa <[email protected]> Date: Sat Sep 7 00:19:16 2019 +0900 Leak fix for OpenSSL 1.0.2 origin https://github.com/espressif/esp-thread-lib.git (fetch) origin https://github.com/espressif/esp-thread-lib.git (push) * (HEAD detached at 9a8d34d) master commit 9a8d34d8f698cad2c9468468b473e26a3dda51b9 Author: Jiacheng Guo <[email protected]> Date: Mon Dec 20 15:58:13 2021 +0800 release: v4.4 (119d3c9) origin https://github.com/espressif/openthread.git (fetch) origin https://github.com/espressif/openthread.git (push) * (HEAD detached at c36c0e77a) main commit c36c0e77a2465355bcf13bd7dc718d8c9aa6ff64 Author: Jonathan Hui <[email protected]> Date: Fri Oct 8 15:39:49 2021 -0700 [cli] use `OT_ERROR_PENDING` instead of `kErrorPending` (espressif#7061) origin https://github.com/protobuf-c/protobuf-c.git (fetch) origin https://github.com/protobuf-c/protobuf-c.git (push) * (HEAD detached at dac1a65) master commit dac1a65feac4ad72f612aab99f487056fbcf5c1a Merge: ab599cf cd573da Author: Robert Edmonds <[email protected]> Date: Sat Aug 5 17:41:36 2017 -0400 Merge pull request espressif#283 from protobuf-c/edmonds/changelog/1.3.0 ChangeLog: 1.3.0 origin https://github.com/pellepl/spiffs.git (fetch) origin https://github.com/pellepl/spiffs.git (push) * (HEAD detached at f5e26c4) master commit f5e26c4e933189593a71c6b82cda381a7b21e41c Author: Peter Andersson <[email protected]> Date: Sat Sep 9 09:27:32 2017 +0200 fixes espressif#165 origin https://github.com/espressif/tinyusb.git (fetch) origin https://github.com/espressif/tinyusb.git (push) * (HEAD detached at c4badd39) master commit c4badd394eda18199c0196ed0be1e2d635f0a5f6 Author: Alex Lisitsyn <[email protected]> Date: Mon Apr 19 13:18:19 2021 +0700 tinyusb: rebase to upstream master, remove unused submodules remove unused submodules rebese `merge pull request espressif#783`: Add new Espressif target esp32s3 for tinyUSB (esp-based_on_334e95f) These submodules are not needed when TinyUSB is built as an ESP-IDF component. We remove them to avoid fetching extra submodules when ESP-IDF is cloned with --recursive flag. Note: this is a local change, not for upstream. origin https://github.com/ThrowTheSwitch/Unity.git (fetch) origin https://github.com/ThrowTheSwitch/Unity.git (push) * (HEAD detached at 7d2bf62) master commit 7d2bf62b7e6afaf38153041a9d53c21aeeca9a25 Merge: e4dfeaa 01cbce8 Author: Mark VanderVoord <[email protected]> Date: Mon Oct 22 10:42:30 2018 -0400 Merge pull request espressif#363 from Deltrix/patch-1 Changed some text issues (Thanks @delrix) origin https://github.com/leethomason/tinyxml2.git (fetch) origin https://github.com/leethomason/tinyxml2.git (push) * (HEAD detached at 7e8e249) master commit 7e8e249990ec491ec15990cf95b6d871a66cf64a Merge: 25b23b8 ade41cd Author: Lee Thomason <[email protected]> Date: Sun Sep 30 17:16:57 2018 -0700 Merge pull request espressif#707 from SwiftEngineering/issue_706 Issue_706: Make resources path relative to current source and binary dir origin https://github.com/espressif/esp-cryptoauthlib.git (fetch) origin https://github.com/espressif/esp-cryptoauthlib.git (push) * (HEAD detached at 36d0642) master commit 36d0642e66ff5b1c7a291873f24c498ca6ffedef Merge: bb672b0 b59f96b Author: Mahavir Jain <[email protected]> Date: Tue Oct 5 05:16:49 2021 +0000 Merge branch 'bugfix/cleanup_freertos_include_path' into 'master' Fix inclusion of freertos specific headers See merge request espressif/esp-cryptoauthlib!9
I wanted to make this available for others before I run out of time on this activity for the short term. The same approach used for reads can be applied for writes to avoid the hardware END-handling state machine bug. The code incorporates the fix by @stickbreaker that I had previously injected (doh!).
The obvious next approach is to try using interrupts for handling the work currently being done on lines 336 to 365 since the current code can be starved of CPU time at points resulting in bus hangs when the state machine is not properly fed.